A typical telecommunication system for real-time communication, or RTC, is based on standardized multimedia technology designated as RTCWeb or WebRTC (the term “WebRTC” will be used herein in place of either designation) by the IETF (Internet Engineering Taskforce) and W3C (World Wide Web Consortium), or generally called RTC, in which a number of similarly standardized protocols are used. The ICE (Interactive Connectivity Establishment, RFC 5245) method used to determine the optimal RTC payload connection in turn uses the STUN (Session Traversal Utilities for NAT (Network Address Translation), RFC 5389) protocol to run so-called “connectivity checks.” These checks determine whether the route in question could in principle be used for the desired payload connection.
In VoIP (Voice-over-Internet-Protocol), the endpoints of a real-time connection (RTP/RTCP) are connected to each other as directly as possible, i.e., without interconnected servers. However, the shortage of IPv4 addresses has led to the fact that in many cases NAT or NAPT (Network Address & Port Translation) is used between Intranet and Internet. This makes it impossible to establish direct contact from the Internet to an Intranet endpoint without taking special measures. This involves ICE (Interactive Connectivity Establishment), which in the VoIP example works together with the SIP signaling protocol and the STUN and TURN (an extension of STUN) protocols. Because ICE does not require any presets for possible connections, as part of its operation all connection candidates are first determined by the endpoints and then simply tested (go/no go, the STUN-based “connectivity check”). These checks are done using a checklist. The list contains all candidates, sorted by priority (from the presumed best connection at the top to the presumed least suitable connection, e.g., via TURN server, at the bottom). The algorithm for establishing the priorities is described in the ICE RFC, but contains only fixed rules that do not account for the current network load or any network interferences.
Because it is important in this description to understand the various scenarios described in the standard, these scenarios are briefly outlined below. The connectivity checks are performed according to the standard in precisely this (priority) sequence (from top to bottom), as shown in FIGS. 1-3.
Next comes the question of why it should be possible for a direct host-host connection (see FIG. 1) to be of poorer quality than one of the other two connections. The answer lies in the fact that the scenarios illustrated above show only the logical structures, without considering the physical characteristics. FIG. 5 (logical network view on top and two physical expressions underneath) demonstrates this concept; although it is logically the same configuration, the quality of the connection established through the two VPN routers (R1, R2) differs significantly from the direct connection (via Ethernet) shown on the left. The connection through the two VPN routers generally has noticeably poorer quality-of-service values.
A VPN can similarly be used in all scenarios, without it being known to the ICE method. Thus, it is always a good idea to consider quality of service in the priority allocation.
However, at present only a few predefined criteria are used as described to decide which route is finally chosen for the payload (i.e., user data). The quality-of-service aspects that are important in the RTC (real-time communication) environment still are often not considered.
At present, with STUN only a “go/no go” test is performed (“connectivity check,” i.e., a test message either does or does not make a complete circuit from sender to STUN server and back again). In particular, QoS (quality of service) aspects that are important for real-time applications are not considered. Of course, in ICE the various alternatives (called candidates) are assigned priorities that should contribute to quality improvement (and, if applicable, cost reduction), but strictly speaking are based on assumptions or guidelines, as shown in the following examples of prioritizing criteria:                IPv6 before IPv4, i.e. strategic guideline;        Direct connection (with no address conversion) before NAT; this is OK with the IP technology, but does not allow any QoS statements;        NAT before TURN (relay); TURN servers are potential bandwidth bottlenecks, and the assumption is therefore understandable, but reliable QoS statements are also not possible.        
The aforementioned STUN connectivity checks are performed in the sequence established by the preceding prioritization. However, the prioritization itself is not influenced by either STUN or other QoS-related criteria.
In summary, the standard IETF ICE procedures, e.g., for WebRTC or SIP systems, test only the basic connectivity (“STUN connectivity checks”) of the offered RTC payload candidate address pairs for the (ICE) communication endpoints (clients, application servers). However, there is no function for considering the QoS characteristics of the various candidate payload paths.